home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48hor2 / library.doc < prev    next >
Internet Message Format  |  1995-03-31  |  9KB
  1. From: charliep@hpcvra.cv.hp.com (Charles Patton) 
  2. Newsgroups: comp.sys.hp48 
  3. Subject: Re: Library Trouble 
  4. Date: 18 Jan 93 
  5. Organization: Hewlett-Packard Co., Corvallis, OR, USA 
  6.  
  7. Since it is difficult to understand remember syntax without semantics, and 
  8. since no one has ever (to my knowledge) made clear to the public at large (or 
  9. even to developers, for that matter) what was the _intended_ usage of the 
  10. attach/configure options are, it is not surprising that it all remains a 
  11. little mysterious. So, here goes.. 
  12.  
  13. ** What is the ATTACH/DETACH stuff? 
  14.  
  15. During the design of the RPL system in '83-'84, we envisioned that plug-ins 
  16. could, and would, serve several distinct functions and and have 
  17. correspondingly distinct needs. 
  18.  
  19. One such function would be to provide a unified, customized, "application 
  20. environment" dedicated to a single purpose and providing both functionality 
  21. and "templates" in the ROM. A good example of this would be a spreadsheet 
  22. application with ready-made forms in ROM which could be customized with 
  23. minimal RAM usage (...think about what that entails!...) Such an application 
  24. would clearly require RAM resources dedicated to it, provide for customized 
  25. interpretation of keywords, commands, etc., and yet not interfere with other 
  26. such applications (even copies of itself!) From this idea we developed the 
  27. notion of a CONTEXT - a RAM/ROM pair consisting of a ROMPART and a RAMPART 
  28. linked together. From the usual user's point of view, this is simply a 
  29. subdirectory, but from a library's ( a.k.a ROMPART's ) point of view, the 
  30. subdirectory is to be considered an extension of the library, and could 
  31. contain data and other RAM resources necessary to the operation of the 
  32. application. 
  33.  
  34. In this kind of "application environment" the user would not "run a program" 
  35. but rather change to the relevant context (subdirectory) where all operations 
  36. would be interpreted according to the information in that context, without 
  37. conflicting with other "application environments" assignments or resources. I 
  38. know of no such "application environments" currently extant for the '48, 
  39. although all the tools necessary to make them are around. 
  40.  
  41. The ATTACH keyword keyword joins a subdirectory (RAMPART) with a library 
  42. (ROMPART) to create such an interpretation context, but if the resources are 
  43. not used by the library, the advantages (other than avoiding conflicts) are 
  44. rather small. Since the subdirectory "belongs" to the library after 
  45. attachment, the attachement is not broken until the system is specifically 
  46. directed to do so (hence the DETACH keyword.) 
  47.  
  48. Obviously, it would be advantageous to allow for a single library to "own" any 
  49. number of subdirectories, say one for each spreadsheet, document, or whatever. 
  50. On the other hand, it would defeat the idea of conflict-avoidance to have 
  51. multiple libraries own (and hence be required to share) a given sub-directory. 
  52. Thus only one library can be attached to a given sub-directory.....except the 
  53. "HOME" directory (a.k.a. SYS RAMROM PAIR).... 
  54.  
  55. Which brings me to a second function envisioned for libraries: localization 
  56. and its relatives. We anticipated the need to produced multi-lingual versions 
  57. of the machine as well as providing for system-wide re-definition of 
  58. high-level aspects of the machine. In order to be able to be re-defined 
  59. on-the-fly, these aspects of the machine (Hash tables for converting text to 
  60. and from commands, and Message tables for defining standarized messages) must, 
  61. at the very least, have "hooks" in RAM. 
  62.  
  63. These "hooks" for Hash and Message tables are provided in the ROMPART of the 
  64. HOME directory. Unlike subdirectories, the HOME directory can have multiple 
  65. libraries "attached" (although "attached" here cannot have same expectation of 
  66. exclusive ownership)  and with each library attachment, a slot for the 
  67. library's Hash and Message table is allocated and filled, by default, with the 
  68. library's own Hash and Message tables. These, however, can be overwritten with 
  69. alternative versions at a later time. 
  70.  
  71. A moment's thought will reveal to you that if you plug in two libraries, one 
  72. to localize the machine to, say, Finnish, and the other to localize it to 
  73. Spanish, at most one of these libraries can succeed. They are obliged to 
  74. "compete" over the fixed resources, and this competition normally occurs at 
  75. warmstart, when a complete inventory of libraries is taken, the HOME ROMPART 
  76. is cleared and re-created anew, and each library is asked, in turn, if there 
  77. is anything it would like to do. 
  78.  
  79. Another kind of library we expected was a system extension attempting to be as 
  80. much like the system (including providing for localization, etc.) as possible. 
  81. They would attach themselves to the HOME directory and do little else, simply 
  82. extending or revising the keyword set. Such libraries have the greatest 
  83. potential for conflicts and unexpected side-effects, since the system is 
  84. tightly integrated and consistency needs to be maintained, but there is no 
  85. mechanism for negotiation at the time of the configuration poll. 
  86.  
  87. A final kind of library we expect was the "run-of-the-mill" kind with a few 
  88. utilities on board, but nothing fancy. Note that it is not necessary to have a 
  89. library attached either to the HOME directory or to any sub-directory for the 
  90. purposes of finding, executing, or displaying any word in any library found 
  91. during the last inventory of libraries. The only aspect of normal library 
  92. operation which requires an attachment is the process of automatically 
  93. associating a library object with a typed-in name (so-called "compilation".) 
  94. This process, however, is modulated by things other than library attachment. 
  95. In particular, any object in the current directory with takes precedence over 
  96. any library object of the same name, no matter where attached. 
  97.  
  98. We expected these run-of-the-mill libraries, then, to take routes, other than 
  99. attachement, to providing access to their utilities, routes which have fewer 
  100. potential conflicts. One such method would be to let the user attach the 
  101. library as desired. Another method would be for the library, in response to 
  102. the configuration poll, to create suitably named variables in RAM, each 
  103. variable consisting of a "rom-pointer" to one of the library words. 
  104.  
  105. In summary... 
  106.  
  107. We expected that application-environment libraries would take this opportunity 
  108. to check that there was at least one of its environments around, and if not, 
  109. to create one... AND THAT'S ALL!! 
  110.  
  111. We expected that localization libraries would redefine the relevant Hash and 
  112. Message tables, with the "winner" of any competition being determined by the 
  113. order in which they are polled as to their preferences. 
  114.  
  115. We expected system-extension libraries, carefully designed and few in number, 
  116. to attach themselves to the HOME directory in the same manner as the main 
  117. system libraries, thus allowing localization of these system extensions. 
  118.  
  119. We expected the bulk of the libraries to not attach themselves anywhere at 
  120. all, but either allow the user to attach as desired, or create RAM-based 
  121. access to their contents, or follow some other convention which didn't require 
  122. attachment. 
  123.  
  124. What has occurred, however, is that the bulk of the libraries, following the 
  125. system library examples, and having little other guidance from our end of the 
  126. street, have chosen to attach themselves automatically to the HOME directory 
  127. insuring a maximum of confusion and conflicts. 
  128.  
  129. **What's the difference between attaching and configuring? 
  130.  
  131. As noted above, the system takes an inventory of libraries in the machine at 
  132. various times (such as, whenever the machine is turned on.) Because we need to 
  133. keep close track of various aspects of the libraries, including their 
  134. location, only libraries in the controlled-access area of the ports (port0, 
  135. port1, and port2) are inventoried. For this reason, you must store a library 
  136. in one of the ports in order to have its existence recognized by the machine. 
  137.  
  138. All libraries which have been found at the last inventory are polled when the 
  139. machine is being re-configured. This happens, for example, whenever a new 
  140. library is found, or an old one is found missing, during the inventory. This 
  141. poll allows the libraries to configure themselves, as described above. During 
  142. this time they may, or may not, attach themselves to a directory or 
  143. subdirectory. 
  144.  
  145. ******************************************************* 
  146. ** Charles M. Patton                                 ** 
  147. **                                                   ** 
  148. ** charliep@cv.hp.com                                ** 
  149. **      the usual disclaimers apply                  ** 
  150. ******************************************************* 
  151.